this is great, was just browsing the docs and surprised it wasn't there

If that's implemented at a component level and doesn't utilize dynamic imports, can we expect a big increase in bundle size?

As effectively, we are importing double the amount of code per optimized component?

I know it won't be exactly a 2x increase, as we aren't optimizing node_modules nor normal functions, but I wonder if this would negatively impact production in a significant way.

Yeah the number of lines per function does get doubled, but the bundle size increase isn't 1:1 with the number of lines since it depends on the compression algorithm. For us, we found that a React Native (Android) project saw an overall increase of ~10% in apk size.

There's some tradeoff math here to do, while bundle size may increase in the gating mode, you will likely see performance benefits in the test case that tradeoff against the bundle size. You'll need to run an experiment to really be sure.

Of course the gating mode is optional too. The Incremental Adoption page covers a bit more about other strategies.

Got it, thanks @poteto!

Another breaking pattern is when you reference a variable declaration inside a callback that was declared after the callback. This can happen accidentally when writing an especially complex component or hook. That callback won't be memoized by the compiler.

Would you consider this a common scenario?
https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAQgIYAmAFAJRHAA6xRchYORhAwgDZ5wBrIgF4itEQD56TIrJZsIPBADoeEAOZU0ECDRlEAvvv2tM7IgG1tEADREwCHADEdAXRFEoDgMo4yOBCoABj1MfRhHWGIAHgo8ADdOTF5+AWFgbj5BAwlgawNogHo4+IkmIzDMDGx8QiIAcR1qOkZmU3MrHTsHZzcPLwRff0CQkzYOTNSPcWEpVrl5M0UVNU1rUNkK8MiYGJKklMF0yezc-KKSsswDEAMgA

Yeah this is a fun case. Note that you can't memoize such callbacks yourself — adding a useCallback() in the "Bad" example in your playground link would be a TDZ violation when you added the dep on foo:

function Bad() {
  const onClick = useCallback(() => {
    console.log(foo)
  }, [foo /* TDZ violation */ ]);
  
  const [foo, setFoo] = useState(0)

  return <div onClick={onClick}>{foo}</div>
}

We can look into adding linting against this pattern to suggest moving the callback. Note that the compiler will already reject this code if you try to manually memoize it, because the dependency changes later.

Would you consider this a common scenario?

Since this pattern doesn't work with manual memoization, this pattern is most likely in code that isn't memoized already. Definitely worth adding validation to help identify opportunities in such code to memoize more.

lowercased to match the types and be more consistent with src/content/reference/react-compiler/panicThreshold.md

❓ Question:

It may not belong to the "incremental adoption" section, but I wonder if it's worth answering the following question in the adoption plan or somewhere else:

There is a recurring question regarding the best practice for handling existing manual memoization APIs (useMemo, useCallback, memo) in a codebase after the React Compiler has been enabled. This uncertainty is common in discussions about adopting the compiler for large, legacy applications.

To address this, we could add a section to the official documentation, that answers the following:

FAQ: What is the recommended strategy for useMemo, useCallback, and memo in a large and legacy codebase after enabling the React Compiler?

Once the compiler is active, should teams begin a gradual process of removing these manual memoizations?
Our working assumption is that this is the intended outcome, as it aligns with the core purpose of the compiler.

Providing clear, official guidance on this topic will significantly reduce community uncertainty and help teams establish a consistent and effective adoption plan.

❓ Question:

Is the use of react-compiler-healthcheck recommended at all?